Cisco Router OSPF Design and Implementation Guide William Parkhurst, PhD, CCIE $54.95 0-07-048626-3 |
![]() |
Chapter: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
Reserve your copy at a Beta Bookstore near you! |
Contact Bet@books © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use. |
During your career in networking you will encounter networks that are utilizing more than one IP routing protocol. Many of the problems that you will find with these networks can be attributed to the interaction of dissimilar protocols due to improper route redistribution. This chapter covers the interaction of RIP, IGRP, EIGRP, and OSPF and how to successfully redistribute routes from one protocol to another. Additionally, you may need to convert a network for one routing protocol such as RIP to a better routing protocol, usually OSPF. Since it is not possible to convert all routers simultaneously the network will be running multiple protocols until the conversion is complete. A firm grasp of protocol interaction is a prerequisite for the efficient and proper conversion from one protocol to another.
RIP and IGRP
The network of figure 13.1 is divided into two routing domains. The first domain, consisting of routers r1 and r2, is running the RIP version 1 routing protocol for networks 172.16.2.0, 172.16.3.0, and 172.16.4.0. The second domain, consisting of routers r3 and r4, is running the Cisco IGRP routing protocol for networks 172.16.4.0, 172.16.5.0, and 172.16.6.0. The goal for this network is for each router to be able to reach every network.
Router r1 configuration
hostname r1
enable password cisco
interface Loopback0
ip address 172.16.2.1 255.255.255.0
interface FastEthernet0/0
ip address 172.16.3.1 255.255.255.0
router rip
network 172.16.0.0
Router r2 configuration
hostname r2
enable password cisco
interface Ethernet0
ip address 172.16.4.1 255.255.255.0
interface FastEthernet0
ip address 172.16.3.2 255.255.255.0
router rip
network 172.16.0.0
Router r3 configuration
hostname r3
enable password cisco
interface Ethernet0
ip address 172.16.4.2 255.255.255.0
interface Serial0
ip address 172.16.5.1 255.255.255.0
bandwidth 38
router igrp 100
network 172.16.0.0
Router r4 configuration
hostname r4
enable password cisco
interface Loopback0
ip address 172.16.6.1 255.255.255.0
interface Serial0
ip address 172.16.5.1 255.255.255.0
bandwidth 38
clock rate 38400
router igrp 100
network 172.16.0.0
What would you expect to see in the routing tables for the four routers? Lets examine the routing tables and determine what is happening.
r1#show ip route
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
R 172.16.4.0/24 [120/1] via 172.16.3.2, 00:00:16, FastEthernet0/0
C 172.16.2.0/24 is directly connected, Loopback0
C 172.16.3.0/24 is directly connected, FastEthernet0/0
r2#show ip route
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.4.0/24 is directly connected, Ethernet0
R 172.16.2.0/24 [120/1] via 172.16.3.1, 00:00:20, FastEthernet0
C 172.16.3.0/24 is directly connected, FastEthernet0
r3#show ip route
172.16.0.0 is variably subnetted, 4 subnets, 2 masks
C 172.16.4.0 255.255.255.0 is directly connected, Ethernet0
C 172.16.5.0 255.255.255.0 is directly connected, Serial0
I 172.16.6.0 255.255.255.0 [100/2760] via 172.16.5.2, 00:00:33, Serial0
r4#show ip route
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
I 172.16.4.0/24 [100/3100] via 172.16.5.1, 00:00:53, Serial0
C 172.16.5.0/24 is directly connected, Serial0
C 172.16.6.0/24 is directly connected, Loopback0
Routers r1 and r2 can see their directly connected networks and the networks that are being advertised by RIP. Routers r3 and r4 can see their directly connected networks and those networks that are being advertised by IGRP. The RIP domain routers cannot see routes from the IGRP domain and the IGRP domain routers cannot see routes from the RIP domain. The link between the two domains, network 172.16.4.0, that is connecting routers r2 and r3 is carrying RIP and IGRP routing updates but there is not a RIP routing process running on r3 so the RIP routes will not be learned. Also, since router r2 is not running an IGRP process, the IGRP routing updates that router r2 receives will be ignored. How do we enable the two domains to see each others routes? In general there are two solutions, static routes and route redistribution. We can use static routes to inform a router of a route that is not being advertised or received by a routing protocol. A static route is created in global configuration mode and has the following format.
r1(config)#ip route ?
A.B.C.D Destination prefix
The destination prefix is the network to which we want to establish the static route. For router r1 there are two networks that it does not have a route for in its routing table, networks 172.16.5.0 and 172.16.6.0. We will build the static route for the network 172.16.5.0.
r1(config)#ip route 172.16.5.0 ?
A.B.C.D Destination prefix mask
The router needs to know which portion of the address to use for the static route. The mask uses the same format as an IP address mask.
r1(config)#ip route 172.16.5.0 255.255.255.0 ?
A.B.C.D Forwarding router's address
FastEthernet FastEthernet IEEE 802.3
Loopback Loopback interface
Null Null interface
The next parameter is either the interface to use when sending packets to the destination network or the IP address of the router that will forward the traffic. For this static route we will use an output interface.
r1(config)#ip route 172.16.5.0 255.255.255.0 fastEthernet 0/0 ?
<1-255> Distance metric for this route
A.B.C.D Forwarding router's address
permanent permanent route
tag Set tag for this route
<cr>
This is the minimum information we need to configure a static route. The other static route for router r1 is to the 172.16.6.0 network.
r1(config)#ip route 172.16.6.0 255.255.255.0 fastEthernet 0/0 ?
The routing table for r1 now contains these new static routes.
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
R 172.16.4.0 [120/1] via 172.16.3.2, 00:00:07, FastEthernet0/0
S 172.16.5.0 is directly connected, FastEthernet0/0
S 172.16.6.0 is directly connected, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
Notice that the static routes appear as directly connected networks connected to the fast ethernet interface. We can now ping all the interfaces on routers r3 and r4. Similarly, to enable routers r2, r3, and r4 to be able to reach all the networks we would need to establish their static routes.
Router r2
ip route 172.16.5.0 255.255.255.0 Ethernet0
ip route 172.16.6.0 255.255.255.0 Ethernet0
Router r3
ip route 172.16.2.0 255.255.255.0 Ethernet0
ip route 172.16.3.0 255.255.255.0 Ethernet0
Router r4
ip route 172.16.2.0 255.255.255.0 Serial0
ip route 172.16.3.0 255.255.255.0 Serial0
We can reduce the number of static routes that need to be configured by using the property of longest match when a router is making a forwarding decision. If we create a static route to network 172.16.0.0, which includes every subnet of 172.16.0.0, then we only need to create one static route.
Router r1
ip route 172.16.0.0 255.255.0.0 FastEthernet0/0
r1#show ip route
172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
R 172.16.4.0/24 [120/1] via 172.16.3.2, 00:00:26, FastEthernet0/0
R 172.16.5.0/24 [120/1] via 172.16.3.2, 00:00:26, FastEthernet0/0
R 172.16.6.0/24 [120/1] via 172.16.3.2, 00:00:26, FastEthernet0/0
S 172.16.0.0/16 is directly connected, FastEthernet0/0
C 172.16.2.0/24 is directly connected, Loopback0
C 172.16.3.0/24 is directly connected, FastEthernet0/0
The routing table for r1 now has two different routes to network 172.16.2.0. The first is using the directly connected interface loopback 0 and the second route is using the directly connected interface fast ethernet 0. Which one will the router use to forward traffic to network 172.16.2.0? The route using the loopback interface has a 24-bit subnet mask and the route using the fast ethernet interface has a 16-bit subnet mask. The loopback route has a longer match on the network address than the static route so the loopback interface will be used.
We have seen in chapter 12 that static routes serve a useful function for tariff networks such as ISDN. For the network of figure 13.1, static routes only impose another administrative burden. The first burden is deciding which static routes are needed and then configuring them on the routers. The second burden is maintaining the static routes. What if we change the network number of the serial link between routers r3 and r4 but use the same major network number? We would have to modify the static routes on routers r1 and r2 (of course if we use the static route 172.16.0.0 then no modification is necessary). If we changed the major network number of the serial link then we would have no choice but to reconfigure the static routes. This is not very difficult on a network of the simplicity of figure 13.1 but if we have tens or hundreds of routers then this task becomes a nightmare and prone to error.
A better solution is to use a dynamic approach instead of a static approach using route redistribution. Route redistribution is the process of taking routes learned from one protocol, such as RIP, and injecting these routes into a different protocol such as IGRP. Since the route costs or metrics are different (usually) between routing protocols we are truly mixing apples and oranges. For our introduction to route redistribution we will cover the mechanics of route redistribution and then try to uncover any snakes that may jump up and bite us.
For route redistribution to occur on a router, the router must be running both of the routing protocols that will engage in the redistribution. For the network of figure 13.1 we have two choices, run RIP and IGRP on router r2 or router r3 as shown in figures 13.2 and 13.3.
For the first redistribution example we will run RIP and IGRP on router r3 as shown in figure 13.2. The first step is to remove the static routes from all the routers by using the no form of the ip route global configuration command. The next step is to enable the RIP routing process and router r3.
Figure 13.2. Running RIP and IGRP on router r3.
Figure 13.3. Running RIP and IGRP on router r2.
Router r3
router rip
network 172.16.0.0
router igrp 100
network 172.16.0.0
The routing table for router r3 now contains routes for the entire network but the other routers do not.
r3#show ip route
172.16.0.0 is variably subnetted, 6 subnets, 2 masks
C 172.16.4.0 255.255.255.0 is directly connected, Ethernet0
C 172.16.5.0 255.255.255.0 is directly connected, Serial0
I 172.16.6.0 255.255.255.0 [100/2760] via 172.16.5.2, 00:01:05, Serial0
R 172.16.2.0 255.255.255.0 [120/2] via 172.16.4.1, 00:00:25, Ethernet0
R 172.16.3.0 255.255.255.0 [120/1] via 172.16.4.1, 00:00:25, Ethernet0
r2#show ip route
172.16.0.0/24 is subnetted, 4 subnets
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:07, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:21, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
Router r3 has learned all the routes because router r3 is now running RIP and IGRP to it is able to receive and process both the RIP and IGRP routing updates. In order for all routers to learn the routes we now need to redistribute them on router r3. In router configuration mode on router r3 we will enable the RIP process to learn the IGRP routes. Once RIP has learned the IGRP routes they will be distributed to routers r2 and r1 using RIP.
r3(config-router)#redistribute igrp ?
<1-65535> Autonomous system number
r3(config-router)#redistribute igrp 100 ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
Select <cr> and examine the routing table for router r2 to see if it has learned the IGRP routes that were redistributed into RIP on router r3.
r2#show ip route
172.16.0.0/24 is subnetted, 4 subnets
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:15, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:02, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
OOPS! Were are the routes to networks 172.16.5.0 and 172.16.6.0? We have just made a classic mistake that is made over and over again, even by experienced router personnel. Remember we are mixing apples and oranges. RIP has a simple hop count for a metric and IGRP has a more sophisticated distance metric. Not only do we need to redistribute the routes we need to turn apples into oranges. We an IGRP route is redistributed into RIP we need to assign a RIP metric to the IGRP route. We forgot to do that in our configuration on router r3 and there are two general ways of assigning the metric. The first is by using the default-metric command.
r3(config)#router rip
r3(config-router)#default-metric ?
<1-4294967295> Default metric
r3(config-router)#default-metric 3 ?
<cr>
The default-metric command used assigns a RIP hop count to every redistributed IGRP route, which can be seen in router r2’s routing table.
r2#show ip route
172.16.0.0/24 is subnetted, 5 subnets
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:04, Ethernet0
R 172.16.6.0 [120/3] via 172.16.4.2, 00:00:04, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:11, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
Router r2 now has routes to networks 172.16.5.0 and 172.16.6.0. Why is the hop count to 172.16.5.0 equal to 1 while the route to 172.16.6.0 is 3? When we enabled RIP on router r3 we instructed RIP to advertise network 176.16.0.0. Router r3 has network 172.16.5.0 as a directly connected network so this route was being advertised before we enabled route redistribution so this is not a redistributed route. The only redistributed route is 172.16.6.0 so this is the only route that will have the default metric applied to it. Another common, and deadly, mistake occurs when assigning the default metric. The default-metric command allows you to enter a default hop count in the range 1-4294967295. Let’s use a large default metric and see what happens.
r3(config)#router rip
r3(config-router)#no default-metric 1
r3(config-router)#default-metric 100
If we do not waste time we can see that the routing table for router r2 now contains
show ip route
172.16.0.0/24 is subnetted, 5 subnets
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:23, Ethernet0
R 172.16.6.0/24 is possibly down, routing via 172.16.4.2, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:11, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
What has happened to the route to network 172.16.6.0? The default metric that was used is greater than the maximum metric for RIP, which is 15. Any route with a hop count of 16 is considered unreachable. Remember that the hold time for RIP is 180 seconds and the flush time is 240 seconds. Router r3 is advertising to router r2 a RIP route with a hop count of 100. After 240 seconds the route will disappear from router r2’s routing table.
r2#show ip route
172.16.0.0/24 is subnetted, 4 subnets
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:21, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:18, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
Try not to forget these common redistribution errors, forgetting a default-metric or using a default-metric that is too large.
Using the default-metric command is a quick and painless way of assigned metrics to redistributed routes. The one major drawback is that the default-metric command assigns this metric to all redistributed routes regardless of how far away they actually are. If we are redistributing more than one protocol into RIP, for example IGRP and OSPF, then all redistributed routes will have the same assigned hop count. For the single or multiple redistributed protocols we can assign a metric with the redistribution command as shown.
r3(config)#router rip
r3(config-router)#redistribute igrp 100 ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
r3(config-router)#redistribute igrp 100 metric ?
<0-4294967295> Default metric
r3(config-router)#redistribute igrp 100 metric 1 ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
r3(config-router)#redistribute igrp 100 metric 1
By assigning the metric with the redistribute command the metric is applied only to the routes learned from IGRP. We can redistribute another protocol with a different metric as shown.
router rip
redistribute igrp 100 metric 1
redistribute eigrp 100 metric 3
network 172.16.0.0
This approach allows for more flexibility when assigning metrics to redistributed routes. Although we are assigning a different metric for each redistributed protocol, for each protocol we are assigning the same metric to every redistributed route. For example we are assigning a default metric of 1 to all the IGRP routes and a metric of 3 to all the EIGRP routes. If the situation arises where we need to assign different metrics to routes redistributed from the same protocol then we must use route maps. For the network of figure 13.4 another loopback interface has been added to router r4 with address 172.16.7.1. We now have two IGRP networks that will be redistributed into RIP on router r3 and both routes will be assigned the same metric as seen by router r2’s routing table.
Figure 13.4. Using route maps to assign different metrics to redistributed routes.
r2#show ip route
172.16.0.0/24 is subnetted, 6 subnets
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:09, Ethernet0
R 172.16.6.0 [120/1] via 172.16.4.2, 00:00:09, Ethernet0
R 172.16.7.0 [120/1] via 172.16.4.2, 00:00:09, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:02, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
Route maps can be used to assign different metrics to routes learned from the same routing protocol. For example, assign a metric of 2 to the network 172.16.6.0 and a metric of 3 to the network 172.16.7.0 and a metric of 1 to any other redistributed IGRP route.
r3(config-router)#redistribute igrp 100 ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
r3(config-router)#redistribute igrp 100 route-map ?
WORD Pointer to route-map entries
r3(config-router)#redistribute igrp 100 route-map adjust_igrp ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
This form of the redistribute command will create a route map named adjust_igrp. A route map is a list of match and set statements similar to an access-list. After the route map has been created we need to add the match and set statements in global configuration mode.
r3(config)#router rip
r3(config-router)#redistribute igrp 100 ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
r3(config-router)#redistribute igrp 100 route-map ?
WORD Pointer to route-map entries
r3(config-router)#redistribute igrp 100 route-map igrp_to_rip
The first step in using a route-map is to inform RIP that a route-map is going to be used to set the metrics of the redistributed routes. The parameter
route-map igrp_to_rip
in the redistribute command informs RIP to consult the route map igrp_to_rip when setting the metrics. The next step is to create the route map. The structure of a route map is similar to an old BASIC program, which used line numbers. Numbered statements are entered into the route map and are executed in numeric order. If a match occurs then the statements in the route map will be executed and the processing of the route map will terminate. For the route map igrp_to_rip we need two operations, one to set the metric of the network 172.16.6.0 to 2 and one to set the metric of the network 172.16.7.0 to 3. Route maps are constructed in global configuration mode.
r3(config)#route-map ?
WORD Route map tag
Enter the name of the route map that was used in the redistribute command under router rip configuration.
r3(config)#route-map igrp_to_rip ?
<0-65535> Sequence to insert to/delete from existing route-map entry
deny Route map denies set operations
permit Route map permits set operations
<cr>
r3(config)#route-map igrp_to_rip permit 10
Like an old BASIC program enter the number for the set of route map commands.
r3(config-route-map)#?
Route Map configuration commands:
exit Exit from route-map configuration mode
help Description of the interactive help system
match Match values from routing table
no Negate or set default values of a command
set Set values in destination routing protocol
Ignoring the exit, help, and no commands leaves us with two choices, match and set. These are usually entered as pairs with the match statement coming first and the set second.
r3(config-route-map)#match ?
as-path Match BGP AS path list
clns CLNS information
community Match BGP community list
interface Match first hop interface of route
ip IP specific information
length Packet length
metric Match metric of route
route-type Match route-type of route
tag Match tag of route
Next enter the item to match. Since we are adjusting IP routes, select ip.
r3(config-route-map)#match ip ?
address Match address of route or match packet
next-hop Match next-hop address of route
route-source Match advertising source address of route
We want to match an IP address, either 172.16.6.0 or 172.16.7.0, so select address.
r3(config-route-map)#match ip address ?
<1-199> IP access-list number
<cr>
Access lists are used for the IP address match function. Since two metrics will be used we will need two access lists, one for the 172.16.6.0 network and one for the 172.16.7.0 network.
r3(config-route-map)#match ip address 1
If the IP address in the access list matches the route that is redistributed then decide what action to take.
r3(config-route-map)#?
Route Map configuration commands:
exit Exit from route-map configuration mode
help Description of the interactive help system
match Match values from routing table
no Negate or set default values of a command
set Set values in destination routing protocol
The action is to set the metric of the route.
r3(config-route-map)#set ?
as-path Prepend string for a BGP AS-path attribute
automatic-tag Automatically compute TAG value
clns OSI summary address
community BGP community attribute
default Set default information
interface Output interface
ip IP specific information
level Where to import route
local-preference BGP local preference path attribute
metric Metric value for destination routing protocol
metric-type Type of metric for destination routing protocol
origin BGP origin code
tag Tag value for destination routing protocol
weight BGP weight for routing table
r3(config-route-map)#set metric ?
+/-<metric> Add or subtract metric
<0-4294967295> Metric value or IGRP bandwidth in Kbits per second
<cr>
r3(config-route-map)#set metric 2
r3(config-route-map)#exit
Return to global configuration and enter the next pair of match and set statements to be used on network 172.16.7.0.
r3(config)#route-map igrp_to_rip permit 20
r3(config-route-map)#match ip address 2
r3(config-route-map)#set metric 3
Finally, return to global configuration mode and create the access-lists.
r3(config)#access-list 1 permit 172.16.6.0 0.0.0.255
r3(config)#access-list 2 permit 172.16.7.0 0.0.0.255
Listing the configuration of router r3 will show what has occurred.
router rip
redistribute igrp 100 route-map igrp_to_rip
network 172.16.0.0
access-list 1 permit 172.16.6.0 0.0.0.255
access-list 2 permit 172.16.7.0 0.0.0.255
route-map igrp_to_rip permit 10
match ip address 1
set metric 2
route-map igrp_to_rip permit 20
match ip address 2
set metric 3
When RIP redistributes a route the route-map igrp_to_rip will be consulted. When network 172.16.6.0 is redistributed, RIP will go through the route-map until either a match is found or RIP comes to the end of the list. If a match is found the set command will be executed. If no matches are found then the effect will be the same as when we forgot to enter a default metric, the route will not be redistributed. The effect of the route map can be seen by examining router r2’s routing table.
r2#show ip route
172.16.0.0/24 is subnetted, 6 subnets
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:14, Ethernet0
R 172.16.6.0 [120/2] via 172.16.4.2, 00:00:24, Ethernet0
R 172.16.7.0 [120/3] via 172.16.4.2, 00:00:24, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:24, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
The two redistributed IGRP now have different metrics due to the operation of the route map. Remember that when statements were added to an access-list, the new statements always were placed at the end of the list. If we wanted to insert a statement in the middle of the list, we were out of luck. The list would have to be deleted and re-entered in the order we wanted. With a route map we can enter a match-set pair of statements anywhere in the list because each pair is numbered. To test this and to test that a route map exits when a match occurs, modify the route-map on router r3 so it contains the additional match-set pair as shown.
route-map igrp_to_rip permit 5
match ip address 1
set metric 6
route-map igrp_to_rip permit 10
match ip address 1
set metric 2
route-map igrp_to_rip permit 20
match ip address 2
set metric 3
The effect of the route map statement 5 is to set the metric of the network 172.16.6.0 to 5, but Statement 10 sets this metric to 2. The second match-set pair will not be executed because after matching the first one RIP will exit processing the route map, which can be verified with router r2’s routing table.
r2#show ip route
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:21, Ethernet0
R 172.16.6.0 [120/6] via 172.16.4.2, 00:00:21, Ethernet0
R 172.16.7.0 [120/3] via 172.16.4.2, 00:00:21, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:14, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
Redistributing IGRP into RIP allows routers r1 and r2 to see all the routes. Router r3’s routing table also contains all the routes since router r3 is running both RIP and IGRP. However, router r4 can still only see the IGRP routes. Before we enable router r4 to also see all the routes return the routers to the following configurations.
Router r1 configuration
hostname r1
enable password cisco
interface Loopback0
ip address 172.16.2.1 255.255.255.0
interface FastEthernet0/0
ip address 172.16.3.1 255.255.255.0
router rip
network 172.16.0.0
Router r2 configuration
hostname r2
enable password cisco
interface Ethernet0
ip address 172.16.4.1 255.255.255.0
interface FastEthernet0
ip address 172.16.3.2 255.255.255.0
router rip
network 172.16.0.0
Router r3 configuration
hostname r3
enable password cisco
interface Ethernet0
ip address 172.16.4.2 255.255.255.0
interface Serial0
ip address 172.16.5.1 255.255.255.0
bandwidth 38400
router rip
redistribute igrp 100 metric 1
network 172.16.0.0
router igrp 100
network 172.16.0.0
Router r4 configuration
hostname r4
enable password cisco
interface Loopback0
ip address 172.16.6.1 255.255.255.0
interface Serial0
ip address 172.16.5.2 255.255.255.0
bandwidth 38
clockrate 38400
router igrp 100
network 172.16.0.0
r3(config-router)#redistribute rip metric ?
<1-4294967295> IGRP bandwidth metric in kilobits per second
r3(config-router)#redistribute rip metric 38 ?
<0-4294967295> IGRP delay metric, in 10 microsecond units
r3(config-router)#redistribute rip metric 38 2000 ?
<0-255> IGRP reliability metric where 255 is 100% reliable
r3(config-router)#redistribute rip metric 38 2000 255 ?
<1-255> IGRP Effective bandwidth metric (Loading) where 255 is 100% loaded
r3(config-router)#redistribute rip metric 38 2000 255 1 ?
<1-4294967295> IGRP MTU of the path
r3(config-router)#redistribute rip metric 38 2000 255 1 1500 ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
If router r4 is to see all the routes then we must redistribute RIP into IGRP on router r3. The form of the command is identical to the one that was used to redistribute IGRP into RIP, the only difference being the assigned metric. When we convert a RIP route into an IGRP route we must assign a five-parameter metric to the RIP routes. Those parameters are bandwidth, delay, reliability, load, and MTU. How do we decide which values to use? We can list the values of these parameters by using the command show interfaces.
r3#show interfaces serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 172.16.5.1 255.255.255.0
MTU 1500 bytes, BW 38 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 0:00:07, output 0:00:03, output hang never
Last clearing of "show interface" counters never
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
10420 packets input, 627195 bytes, 0 no buffer
Received 10036 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
11404 packets output, 739139 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets, 0 restarts
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
r3#show interfaces ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c5c.2a90 (bia 0000.0c5c.2a90)
Internet address is 172.16.4.2 255.255.255.0
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 4:00:00
Last input 0:00:00, output 0:00:00, output hang never
Last clearing of "show interface" counters never
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 1000 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
8283 packets input, 856890 bytes, 0 no buffer
Received 4319 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
14122 packets output, 1352048 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets, 0 restarts
0 output buffer failures, 0 output buffers swapped out
We can see the values of the five IGRP parameters for each interface but which set of parameters should be used, the set for the serial interface or the set for the ethernet interface? Since we are going to redistribute RIP routes, routes that are reached over the ethernet interface, the set of parameters for the ethernet interface should be used. The cost of the serial interface will be added to the route cost. If we use the metrics associated with the ethernet interface then all RIP routes will be assigned the same cost (assuming we are not using route maps to assign a different cost to each individual redistributed RIP route). This situation is acceptable because the cost of all RIP routes to router r2 is identical. Once traffic has reached router r2, router r2 will make a routing decision based upon the lowest RIP hop count. The RIP routes are redistributed on router r3 as shown below.
r3(config)#router igrp 100
r3(config-router)#redistribute ?
bgp Border Gateway Protocol (BGP)
connected Connected
egp Exterior Gateway Protocol (EGP)
eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)
igrp Interior Gateway Routing Protocol (IGRP)
isis ISO IS-IS
iso-igrp IGRP for OSI networks
mobile Mobile routes
ospf Open Shortest Path First (OSPF)
rip Routing Information Protocol (RIP)
static Static routes
r3(config-router)#redistribute rip ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
r3(config-router)#redistribute rip metric ?
<1-4294967295> IGRP bandwidth metric in kilobits per second
r3(config-router)#redistribute rip metric 10000 ?
<0-4294967295> IGRP delay metric, in 10 microsecond units
r3(config-router)#redistribute rip metric 10000 100 ?
<0-255> IGRP reliability metric where 255 is 100% reliable
r3(config-router)#redistribute rip metric 10000 100 255 ?
<1-255> IGRP Effective bandwidth metric (Loading) where 255 is 100% loaded
r3(config-router)#redistribute rip metric 10000 100 255 1 ?
<1-4294967295> IGRP MTU of the path
r3(config-router)#redistribute rip metric 10000 100 255 1 1500 ?
metric Metric for redistributed routes
route-map Route map reference
<cr>
r3(config-router)#redistribute rip metric 10000 100 255 1 1500
Notice that the delay value entered is 100 instead of 1000 as shown for the ethernet interface. The interface delay value must be divided by 10 before entering it as an IGRP metric.
At this point, router r4 should have learned all the RIP routes that were redistributed in IGRP.
r4#show ip route
172.16.0.0/24 is subnetted, 5 subnets
I 172.16.4.0 [100/265257] via 172.16.5.1, 00:00:02, Serial0
C 172.16.5.0 is directly connected, Serial0
C 172.16.6.0 is directly connected, Loopback0
I 172.16.2.0 [100/265257] via 172.16.5.1, 00:00:02, Serial0
I 172.16.3.0 [100/265257] via 172.16.5.1, 00:00:02, Serial0
Another command to list IP routes and their metrics is to use show ip route <IP address of the destination network>. Using this form of the show ip route command we can list the information that router r4 has concerning the route to network 172.16.2.0.
r4#show ip route 172.16.2.0
Routing entry for 172.16.2.0/24
Known via "igrp 100", distance 100, metric 265257
Redistributing via igrp 100
Advertised by igrp 100 (self originated)
Last update from 172.16.5.1 on Serial0, 00:01:07 ago
Routing Descriptor Blocks:
* 172.16.5.1, from 172.16.5.1, 00:01:07 ago, via Serial0
Route metric is 265257, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 38 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
The route was learned via IGRP and has an administrative distance of 100 (the default for IGRP). The IGRP metric is 265257, which consists of the 4 metrics: bandwidth, delay, load, and reliability. The total delay is 21000, which is the sum of the delay for the serial link (20000) and the delay of the ethernet link (1000). Using the four metrics for the ethernet and serial interfaces the total cost can be calculated using the IGRP metric formula
Metric1 = K1 * (10,000,000/Bandwidth) + (K2 * 10,000,000/Bandwidth)/(256 – load) + K3 * Delay/10
Final Metric = Metric1 + (K5/(reliability + K4))
The default values for K1, K2, K3, K4, and K5 are
K1 = K3 = 1
K2 = K4 = K5 = 0.
The bandwidth used in the metric formula is the smallest bandwidth of the path in units of 1 kbit. The smallest bandwidth is associated with the serial link to the bandwidth used in the formula is 38000/1000 = 38. So the Final Metric equation reduces to
Final Metric = (10,000,000/38) + Total Delay/10 (10,000,000/38) + (21000/10) = 265,257.
Now we will examine the other types of routes that we can redistribute into any of the IP routing protocols.
r3(config-router)#redistribute ?
bgp Border Gateway Protocol (BGP)
connected Connected
egp Exterior Gateway Protocol (EGP)
eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)
igrp Interior Gateway Routing Protocol (IGRP)
isis ISO IS-IS
iso-igrp IGRP for OSI networks
mobile Mobile routes
ospf Open Shortest Path First (OSPF)
rip Routing Information Protocol (RIP)
static Static routes
In particular we are interested in the highlighted selections, connected and static. Redistributing connected routes for RIP and IGRP can be an alternation to using the network command under router configuration mode. The operative phrase here is "can be". Reconfigure the IGRP routing process on router r3 to redistribute connected routes without using the network command.
router igrp 100
redistribute connected
redistribute rip metric 10000 100 255 1 1500
Router r3’s connected networks are 172.16.4.0 and 172.16.5.0. Now examine the routing table for router r4.
r4#show ip route
172.16.0.0/24 is subnetted, 2 subnets
C 172.16.5.0 is directly connected, Serial0
C 172.16.6.0 is directly connected, Loopback0
Router r4 has lost all routes exit for its directed connected networks. When we reconfigured IGRP on router r3 we did not use any network statements. The network statement is used not only to inform IGRP of the networks to advertise but also which interfaces to send and receive IGRP routing updates. Without a network command the IGRP process on router r3 will do nothing, so router r4 will not learn any routes. A better illustration of redistributed connected routes is to create a loopback interface on router r3 in a different major network than 172.16.0.0. For this demonstration the network 156.26.1.0 will be used.
Router r3 configuration
interface Loopback0
ip address 156.26.1.1 255.255.255.0
router igrp 100
redistribute connected
redistribute rip metric 10000 100 255 1 1500
network 172.16.0.0
With this configuration, router r3 will run IGRP over interfaces in the 172.16.0.0 network. Since network 156.26.0.0 is on a directly connected interface, the redistribute connected command will force IGRP to advertise this network also. As seen by router r4’s routing table.
r4#show ip route
I 156.26.0.0/16 [100/265657] via 172.16.5.1, 00:00:40, Serial0
172.16.0.0/24 is subnetted, 5 subnets
I 172.16.4.0 [100/265257] via 172.16.5.1, 00:00:40, Serial0
C 172.16.5.0 is directly connected, Serial0
C 172.16.6.0 is directly connected, Loopback0
I 172.16.2.0 [100/265257] via 172.16.5.1, 00:00:40, Serial0
I 172.16.3.0 [100/265257] via 172.16.5.1, 00:00:40, Serial0
For RIP, IGRP, and EIGRP the redistribute connected command essentially can be used to replace the network command as long as at lest one network command has been used. Will IGRP advertise routes out the 156.26.1.0 interface? We can debug IGRP transactions to determine whether or not routes will be sent onto the 156.26.0.0 network.
r3#debug ip igrp transactions
IGRP protocol debugging is on
r3#
IGRP: sending update to 255.255.255.255 via Ethernet0 (172.16.4.2)
subnet 172.16.5.0, metric=265157
subnet 172.16.6.0, metric=265657
network 156.26.0.0, metric=501
IGRP: sending update to 255.255.255.255 via Serial0 (172.16.5.1)
subnet 172.16.4.0, metric=1100
subnet 172.16.2.0, metric=1100
subnet 172.16.3.0, metric=1100
network 156.26.0.0, metric=501
As we can see, routing updates are not sent onto the 156.26.0.0 network. IGRP will only broadcast routing updates out interfaces that are contained in the network statements. The equivalent commands to redistribute connected would be
router igrp 100
passive-interface Loopback0
network 156.26.0.0
network 172.16.0.0
r3#debug ip igrp transactions
IGRP protocol debugging is on
r3#
IGRP: sending update to 255.255.255.255 via Ethernet0 (172.16.4.2)
subnet 172.16.5.0, metric=265157
subnet 172.16.6.0, metric=265657
network 156.26.0.0, metric=501
IGRP: sending update to 255.255.255.255 via Serial0 (172.16.5.1)
subnet 172.16.4.0, metric=1100
subnet 172.16.2.0, metric=1100
subnet 172.16.3.0, metric=1100
network 156.26.0.0, metric=501
From the debugging output for both cases we can see that the same information is being broadcast out the same interfaces. You may ask what is the benefit of having a redistributed connected command when we can achieve the same result using network and passive interface commands. This question will be answered when we examine route redistribution with OSPF.
The next redistribute command that we will examine is redistribute static. Static routes are useful, as we have seen, when we want to prevent routing traffic over an ISDN connection. The redistribute static command simply advertises any static routes that have been configured on the router. For example, create a static route to the network 200.16.10.0 on router r3.
r3(config)#ip route 200.16.10.0 255.255.255.0 ethernet 0
Router r3 now has a static route to network 200.16.10.0.
r3#show ip route
156.26.0.0 255.255.255.0 is subnetted, 1 subnets
C 156.26.1.0 is directly connected, Loopback0
172.16.0.0 255.255.255.0 is subnetted, 5 subnets
C 172.16.4.0 is directly connected, Ethernet0
C 172.16.5.0 is directly connected, Serial0
I 172.16.6.0 [100/265657] via 172.16.5.2, 00:00:13, Serial0
R 172.16.2.0 [120/2] via 172.16.4.1, 00:00:25, Ethernet0
R 172.16.3.0 [120/1] via 172.16.4.1, 00:00:25, Ethernet0
S 200.16.10.0 is directly connected, Ethernet0
Even though the static route appears as a directly connected route, router r3 will not advertise this route if we use the redistribute connected command as shown by router r4’s routing table.
r4#sh ip route
I 156.26.0.0/16 [100/265657] via 172.16.5.1, 00:00:02, Serial0
172.16.0.0/24 is subnetted, 5 subnets
I 172.16.4.0 [100/265257] via 172.16.5.1, 00:00:02, Serial0
C 172.16.5.0 is directly connected, Serial0
C 172.16.6.0 is directly connected, Loopback0
I 172.16.2.0 [100/265257] via 172.16.5.1, 00:00:02, Serial0
I 172.16.3.0 [100/265257] via 172.16.5.1, 00:00:02, Serial0
In order to advertise the static route to 200.16.10.0 the redistribute static command must be used under router igrp configuration mode.
router igrp 100
redistribute connected
redistribute static
redistribute rip metric 10000 100 255 1 1500
network 172.16.0.0
Which will force the IGRP process on router r3 to advertise the static route as shown by router r4's routing table.
r4#show ip route
I 156.26.0.0/16 [100/265657] via 172.16.5.1, 00:00:03, Serial0
172.16.0.0/24 is subnetted, 5 subnets
I 172.16.4.0 [100/265257] via 172.16.5.1, 00:00:03, Serial0
C 172.16.5.0 is directly connected, Serial0
C 172.16.6.0 is directly connected, Loopback0
I 172.16.2.0 [100/265257] via 172.16.5.1, 00:00:03, Serial0
I 172.16.3.0 [100/265257] via 172.16.5.1, 00:00:03, Serial0
I 200.16.10.0/24 [100/265257] via 172.16.5.1, 00:00:03, Serial0
There is a special static route called a default route. A default route is a route to network 0.0.0.0. A default route is used when a router receives a packet that is destined for a network that is not in the router’s routing table. A default route is created as a static route to network 0.0.0.0. Create a default router on router r2.
r2(config)#ip route 0.0.0.0 255.255.255.255 fastEthernet 0
r2#show ip route
r2#show ip route
172.16.0.0/24 is subnetted, 5 subnets
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:07, Ethernet0
R 172.16.6.0 [120/1] via 172.16.4.2, 00:00:07, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:27, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
S 0.0.0.0/32 is directly connected, FastEthernet0
Configure the RIP routing process on router r2 with the redistribute static command. Even though router r2 has a route to the default network and it has been declared as a static route the command redistribute static will not cause this route to be advertised by RIP as seen by router r1’s routing table.
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
R 172.16.4.0 [120/1] via 172.16.3.2, 00:00:03, FastEthernet0/0
R 172.16.5.0 [120/2] via 172.16.3.2, 00:00:03, FastEthernet0/0
R 172.16.6.0 [120/2] via 172.16.3.2, 00:00:03, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
To redistribute the default route so all routers can see it without having to create a default static route on every router we can use the default-information originate command under RIP router configuration mode on router r2.
r2(config-router)#default-information ?
originate Distribute a default route
r2(config-router)#default-information originate ?
route-map Route-map reference
<cr>
r2(config-router)#default-information originate
The routing table for router r1 now contains the default route.
r1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is 172.16.3.2 to network 0.0.0.0
172.16.0.0/24 is subnetted, 5 subnets
R 172.16.4.0 [120/1] via 172.16.3.2, 00:00:24, FastEthernet0/0
R 172.16.5.0 [120/2] via 172.16.3.2, 00:00:24, FastEthernet0/0
R 172.16.6.0 [120/2] via 172.16.3.2, 00:00:24, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
R* 0.0.0.0/0 [120/1] via 172.16.3.2, 00:00:24, FastEthernet0/0
If router r1 receives a packet to a network not in router r1’s routing table the packet will be sent onto interface fast ethernet 0.
One of the commands that we skipped in chapter 11, Configuring IGRP, was the metric weights command. This command is used to modify the constants K1, K2, K3, K4, and K5 in the IGRP metric equation. The syntax of the command is given below.
r3(config)#router igrp 100
r3(config-router)#metric weights ?
<0-8> Type Of Service (Only TOS 0 supported)
r3(config-router)#metric weights 0 ?
<0-4294967295> K1
r3(config-router)#metric weights 0 1 ?
<0-4294967295> K2
r3(config-router)#metric weights 0 1 0 ?
<0-4294967295> K3
r3(config-router)#metric weights 0 1 0 1 ?
<0-4294967295> K4
r3(config-router)#metric weights 0 1 0 1 0 ?
<0-4294967295> K5
r3(config-router)#metric weights 0 1 0 1 0 0
Although the constants K1 through K5 can be modified, don’t do it! These values have been chosen for the optimum operation of the IGRP routing protocol. Modifying these values will probably cause you nothing but trouble. But if you are ever asked to modify them, now you know how.
Although we did not look at any examples of using route maps with redistributed connected and static routes, route maps can be used in the same manner that we used them for redistributing routes from other routing protocols.
The final configuration example that we need to explore concerns mutual redistribution. The network is configured so that router r3 is redistributing RIP routes into IGRP and IGRP routes into RIP. Mutual redistribution can sometimes cause routing loops to occur. The problem occurs when redistributed routes are re-advertised using another protocol. For example, router r3 is advertising to router r4 that it can reach network 172.16.2.0. Network 172.16.2.0 was learned from RIP and redistributed into IGRP. Router r4 receives this route advertisement from router r3 but does not re-advertise the route to router r3 because of split horizon. IP split horizon is enabled by default on IP interfaces so router r4 will not advertise to router r3 that it has a route to network 172.16.2.0 since router r4 learned this route from router r3. What would happen if we disabled IP split horizon on router r4’s serial interface? Let’s do it and see what happens. Disable IP split horizon on the serial interface between router r3 and router r4 on router r4’s serial interface. Before we disable IP split horizon, look at the routing table for router r3 and determine the route to 172.16.2.0.
r3#show ip route
Gateway of last resort is 172.16.4.1 to network 0.0.0.0
156.26.0.0 255.255.255.0 is subnetted, 1 subnets
C 156.26.1.0 is directly connected, Loopback0
172.16.0.0 255.255.255.0 is subnetted, 5 subnets
C 172.16.4.0 is directly connected, Ethernet0
C 172.16.5.0 is directly connected, Serial0
I 172.16.6.0 [100/265657] via 172.16.5.2, 00:00:06, Serial0
R 172.16.2.0 [120/2] via 172.16.4.1, 00:00:11, Ethernet0
R 172.16.3.0 [120/1] via 172.16.4.1, 00:00:11, Ethernet0
S 200.16.10.0 is directly connected, Ethernet0
R* 0.0.0.0 0.0.0.0 [120/1] via 172.16.4.1, 00:00:11, Ethernet0
As expected, router r3 has a route to network 172.16.2.0 through router r2. Now disable split horizon on the serial interface of router r4.
r4(config)#interface serial 0
r4(config-if)#no ip split-horizon
Now examine router r3’s routing table.
r3#show ip route
156.26.0.0 is variably subnetted, 2 subnets, 2 masks
I 156.26.0.0 255.255.0.0 [100/267657] via 172.16.5.2, 00:01:03, Serial0
C 156.26.1.0 255.255.255.0 is directly connected, Loopback0
172.16.0.0 255.255.255.0 is subnetted, 5 subnets
C 172.16.4.0 is directly connected, Ethernet0
C 172.16.5.0 is directly connected, Serial0
I 172.16.6.0 [100/265657] via 172.16.5.2, 00:01:04, Serial0
I 172.16.2.0 [100/267257] via 172.16.5.2, 00:01:04, Serial0
I 172.16.3.0 [100/267257] via 172.16.5.2, 00:01:04, Serial0
S 200.16.10.0 is directly connected, Ethernet0
R* 0.0.0.0 0.0.0.0 [120/1] via 172.16.4.1, 00:00:26, Ethernet0
Router r3 now thinks that it has a route to networks 172.16.2.0 and 172.16.3.0 through router r4! How can this be? The answer is apples and oranges. Figure 13.5 shows the process that has caused these routes to be installed in router r3’s routing table. In figure 13.5, router r2 is advertising to router r3 routes to networks 172.16.2.0 and 172.16.3.0. Router r3 is running RIP so these two routes will be added to the routing table. Router r3 redistributes these two routes into IGRP and advertises them as IGRP routes to router r4 Since IP split horizon is disabled on router r4 it will advertise to router r3 that it has a route to networks 172.16.2.0 and 172.16.3.0. Router r3 is now receiving advertisements to networks 172.16.2.0 and 172.16.3.0 from routers r2 and r4 . Which routes will be installed in the routing tables. Router r3 cannot use the route metrics to decide since the metric for RIP is not comparable to the metric for IGRP (apples and oranges). This is when the administrative distance comes into play. The administrative distance for RIP is 120 and for IGRP the administrative distance is 100, so the IGRP route is preferred. The RIP routes will be ignored and the IGRP routes will be installed in the routing table. Even worse, router r4 has routes to networks 172.16.2.0 and 172.16.3.0 that point to router r3.
Figure 13.5. Formation of a routing loop.
r4#show ip route
I 156.26.0.0/16 [100/265657] via 172.16.5.1, 00:00:07, Serial0
172.16.0.0/24 is subnetted, 5 subnets
I 172.16.4.0 [100/265257] via 172.16.5.1, 00:00:07, Serial0
C 172.16.5.0 is directly connected, Serial0
C 172.16.6.0 is directly connected, Loopback0
I 172.16.2.0 [100/265257] via 172.16.5.1, 00:00:25, Serial0
I 172.16.3.0 [100/265257] via 172.16.5.1, 00:00:25, Serial0
I 200.16.10.0/24 [100/265257] via 172.16.5.1, 00:00:08, Serial0
We now have a classic routing loop. If we trace the route from router r4 to network 172.16.2.0 we can see this loop in action.
r4#traceroute
Protocol [ip]:
Target IP address: 172.16.2.1
Source address:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]: v
Loose, Strict, Record, Timestamp, Verbose[V]:
Type escape sequence to abort.
Tracing the route to 172.16.2.1
1 172.16.5.1 24 msec 24 msec 24 msec
2 172.16.5.2 60 msec 44 msec 44 msec
The packet is bouncing between routers r3 and r4. This example may be somewhat artificial because for this configuration we would probably never disable split horizon. But if we are running IGRP and RIP across a point-to-multipoint NBMA network using subinterfaces then this exact problem can occur. We need to disable IP split horizon on the hub router (Figure 13.6) so the routing updates can be propagated to all the routers. If in additional route redistribution is taking place, then a routing loop can occur.
Figure 13.6. NBMA multipoint configuration where split horizon needs to be disabled.
The final note for RIP and IGRP route redistribution concerns redistributing routes between routing domains that are employing different length subnet masks. We have already seen the effects of using VLSM in a RIP or IGRP routing domain and the problems associated with doing so. The question at hand is how will route redistribution be effected if the two routing domains, RIP and IGRP, use a different length subnet mask. There are two cases that need to be examined. The first is using a different length subnet mask using the same major network number. The second case is using a different length subnet mask and a different major network number. For the first case we will retain the 8-bit subnet mask for the RIP domain and use a 12-bit subnet mask for the IGRP domain as shown in figure. The only configuration changes occur on routers r3 and r4. Also, remove all static and default routes and remove the redistribute static and connected commands on router r3.
Router r3 configuration changes
interface Serial0
ip address 176.16.5.1 255.255.255.240
bandwidth 38
Router r4 configuration changes
interface Loopback0
ip address 172.16.6.1 255.255.255.240
interface Serial0
ip address 176.16.5.2 255.255.255.240
bandwidth 38
clockrate 38400
With the above changes the routing table for router r4 now contains
r4#show ip route
172.16.0.0/28 is subnetted, 2 subnets
C 172.16.5.0 is directly connected, Serial0
C 172.16.6.0 is directly connected, Loopback0
All the routes that were previously learned from RIP have now disappeared. As we might have expected, since the subnet masks between the two routing domains are different, the routes will not be redistributed. The problem can be solved by creating static routes to networks 172.16.2.0, 172.16.3.0, and 172.16.4.0 with an 8-bit subnet mask on router r4 or creating the static routes on router r3 and redistributing them into IGRP. Since router r3 has already learned the routes to these networks via RIP, the best place to configure the static routes is on router r4.
Router r4 configuration
ip route 172.16.2.0 255.255.255.0 Serial0
ip route 172.16.3.0 255.255.255.0 Serial0
ip route 172.16.4.0 255.255.255.0 Serial0
Notice that an 8-bit subnet mask was used for the static routes and not a 12-bit subnet mask. Since these are static routes and not routes learned form IGRP the 8-bit subnet mask will work. If the static routes were created on router r3 and redistributed into IGRP then a 12-bit subnet mask would need to be used. To see if the static routes have solved our problem, try pinging interfaces on networks 172.16.2.0, 172.16.3.0, and 172.16.4.0 from router r4. Router r4 can ping 172.16.4.2 since this interface is directly connected to router r3 and router r3 is running IGRP so it has a route back to router r4. Router r4 cannot ping 172.16.4.1 since router r2 does not have a router back to router r2 because of the subnet mask mismatch between the RIP and IGRP domains. Static routes need to be entered on router r2 and redistributed into RIP so router r1 will learn about their existence.
Router r2 configuration
router rip
redistribute static metric 1
network 172.16.0.0
ip route 172.16.5.0 255.255.255.0 Ethernet0
ip route 172.16.6.0 255.255.255.0 Ethernet0
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
R 172.16.4.0 [120/1] via 172.16.3.2, 00:00:07, FastEthernet0/0
R 172.16.5.0 [120/1] via 172.16.3.2, 00:00:07, FastEthernet0/0
R 172.16.6.0 [120/1] via 172.16.3.2, 00:00:07, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
Router r1 now has routes to the IGRP networks and router r4 can ping the RIP networks and router r1 can ping the IGRP networks.
In order to examine case two where the IGRP domain uses a different major network number than RIP and a different length subnet mask configure routers r3 and r4 as shown. Remove any static routes from the routers and any redistribute static commands.
Router r3 configuration
interface Serial0
ip address 173.16.5.1 255.255.255.240
bandwidth 38
router rip
redistribute igrp 100 metric 1
network 172.16.0.0
router igrp 100
redistribute rip metric 10000 100 255 1 1500interface Loopback0
ip address 173.16.6.1 255.255.255.240
Router r4 configuration
interface Serial0
ip address 173.16.5.2 255.255.255.240
bandwidth 38
clockrate 38400
router igrp 100
network 173.16.0.0
The routing tables for routers r1 and r4 now contain routes to the other routing domains.
r1#show ip route
172.16.0.0/24 is subnetted, 3 subnets
R 172.16.4.0 [120/1] via 172.16.3.2, 00:00:11, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
R 173.16.0.0/16 [120/2] via 172.16.3.2, 00:00:11, FastEthernet0/0
r4#show ip route
I 172.16.0.0/16 [100/265257] via 173.16.5.1, 00:00:26, Serial0
173.16.0.0/28 is subnetted, 2 subnets
C 173.16.5.0 is directly connected, Serial0
C 173.16.6.0 is directly connected, Loopback0
We have covered the scenarios that can occur when redistributing between RIP and IGRP. Many of the scenarios that were examined and commands that were used are applicable when redistributing routes between protocols other than RIP and IGRP. For the remaining combinations of routing protocols I will only examine issues that are unique to the routing protocol pairs under discussion.
RIP and EIGRP
The network of figure 13.7 will be used to examine the interaction between RIP and EIGRP when redistributing routes. Configure routers r1, r2, r3, and r4 as shown.
Figure 13.7. Example network for RIP and EIGRP route redistribution.
Router r1 configuration
hostname r1
enable password cisco
interface Loopback0
ip address 172.16.2.1 255.255.255.0
interface FastEthernet0/0
ip address 172.16.3.1 255.255.255.0
router rip
network 172.16.0.0
Router r2 configuration
hostname r2
enable password cisco
interface Ethernet0
ip address 172.16.4.1 255.255.255.0
interface FastEthernet0
ip address 172.16.3.2 255.255.255.0
router rip
network 172.16.0.0
Router r3 configuration
hostname r3
enable password cisco
interface Ethernet0
ip address 172.16.4.2 255.255.255.0
interface Serial0
ip address 172.16.5.1 255.255.255.0
bandwidth 38
router rip
redistribute eigrp 100 metric 1
network 172.16.0.0
router eigrp 100
redistribute rip metric 10000 100 255 1 1500
network 172.16.0.0
Router r4 configuration
hostname r4
enable password cisco
interface Loopback0
ip address 172.16.6.1 255.255.255.0
interface Serial0
ip address 172.16.5.2 255.255.255.0
bandwidth 38
clockrate 38400
router eigrp 100
network 172.16.0.0
The only difference between this RIP/EIGRP configuration and the first RIP/IGRP is that we are running EIGRP instead of IGRP. Previous experience tells us that this configuration should present no routing problems as show by the routing tables.
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
R 172.16.4.0 [120/1] via 172.16.3.2, 00:00:11, FastEthernet0/0
R 172.16.5.0 [120/2] via 172.16.3.2, 00:00:11, FastEthernet0/0
R 172.16.6.0 [120/2] via 172.16.3.2, 00:00:11, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
r2#show ip route
172.16.0.0/24 is subnetted, 5 subnets
C 172.16.4.0 is directly connected, Ethernet0
R 172.16.5.0 [120/1] via 172.16.4.2, 00:00:01, Ethernet0
R 172.16.6.0 [120/1] via 172.16.4.2, 00:00:01, Ethernet0
R 172.16.2.0 [120/1] via 172.16.3.1, 00:00:11, FastEthernet0
C 172.16.3.0 is directly connected, FastEthernet0
r3#show ip route
172.16.0.0 255.255.255.0 is subnetted, 5 subnets
C 172.16.4.0 is directly connected, Ethernet0
C 172.16.5.0 is directly connected, Serial0
D 172.16.6.0 [90/68008192] via 172.16.5.2, 00:07:36, Serial0
R 172.16.2.0 [120/2] via 172.16.4.1, 00:00:14, Ethernet0
R 172.16.3.0 [120/1] via 172.16.4.1, 00:00:14, Ethernet0
r4#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 5 subnets
D 172.16.4.0 [90/67905792] via 172.16.5.1, 00:08:18, Serial0
C 172.16.5.0 is directly connected, Serial0
C 172.16.6.0 is directly connected, Loopback0
D EX 172.16.2.0 [170/68136192] via 172.16.5.1, 00:02:49, Serial0
D EX 172.16.3.0 [170/68136192] via 172.16.5.1, 00:02:49, Serial0
Notice that the routes learned from RIP and redistributed into EIGRP are tagged as external routes.
The scenarios left to examine are using different length subnet masks on the same major network number and different length subnet masks on a different major subnet number. For the first scenario configure routers r3 and r4 as shown.
Router r3 configuration
interface Serial0
ip address 172.16.5.1 255.255.255.240
bandwidth 38
Router r4 configuration
interface Loopback0
ip address 172.16.6.1 255.255.255.240
interface Serial0
ip address 172.16.5.2 255.255.255.240
bandwidth 38
no fair-queue
clockrate 38400
Since EIGRP carries subnet information in the routing updates we should expect to see the redistributed RIP routes in router r4’s routing table.
r4#show ip route
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.4.0/24 [90/67905792] via 172.16.5.1, 00:00:49, Serial0
C 172.16.5.0/28 is directly connected, Serial0
C 172.16.6.0/28 is directly connected, Loopback0
D EX 172.16.2.0/24 [170/68136192] via 172.16.5.1, 00:00:49, Serial0
D EX 172.16.3.0/24 [170/68136192] via 172.16.5.1, 00:00:49, Serial0
But we should not see the EIGRP routes in router r1’s routing table since RIP does not carry subnet information in the routing updates.
r1#show ip route
172.16.0.0/24 is subnetted, 3 subnets
R 172.16.4.0 [120/1] via 172.16.3.2, 00:00:02, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
Using EIGRP instead of IGRP has solved half of our routing problem, namely that the EIGRP domain can see the RIP routes. What can we do to enable the RIP domain to see the EIGRP routes? Static routes can be created on router r2 on then redistributed into RIP as was done with RIP/IGRP. Or we can use RIP version 2 on routers r1, r2 and r3. Re-configure the RIP processes as version 2 on routers r1, r2, and r3 and then re-examine router r1’s routing table.
r1#show ip route
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
R 172.16.4.0/24 [120/1] via 172.16.3.2, 00:00:01, FastEthernet0/0
R 172.16.5.0/28 [120/2] via 172.16.3.2, 00:00:01, FastEthernet0/0
R 172.16.6.0/28 [120/2] via 172.16.3.2, 00:00:01, FastEthernet0/0
C 172.16.2.0/24 is directly connected, Loopback0
C 172.16.3.0/24 is directly connected, FastEthernet0/0
The final scenario, where the domains are using different length subnet masks and different major network numbers, will work identically to the same scenario that was examined for RIP/IGRP route redistribution, regardless of the version of RIP that is running.
From the routing table listing for router r3 we can determine the EIGRP metric.
D 172.16.6.0 [90/68008192] via 172.16.5.2, 00:07:36, Serial0
We have seen how to calculate the IGRP metric so how do we calculate the EIGRP metric? The IGRP metric for the same route was shown to be
I 172.16.6.0 [100/265657] via 172.16.5.2, 00:00:13, Serial0.
If we divide the EIGRP metric by the IGRP metric we can determine the relationship between the metrics.
68008192/265657 = 256
The EIGRP metric is always 256 times the IGRP metric.
IGRP and EIGRP
In order to determine the relationship between redistributing routes between IGRP and EIGRP, configure the network shown in figure 13.8 with the following configurations.
Router r1 configuration
hostname r1
enable password cisco
interface Loopback0
ip address 172.16.2.1 255.255.255.0
interface FastEthernet0/0
ip address 172.16.3.1 255.255.255.0
router igrp 100
network 172.16.0.0
Router r2 configuration
hostname r2
enable password cisco
interface Ethernet0
ip address 172.16.4.1 255.255.255.0
interface FastEthernet0
ip address 172.16.3.2 255.255.255.0
router igrp 100
network 172.16.0.0
Router r3 configuration
hostname r3
enable password cisco
interface Ethernet0
ip address 172.16.4.2 255.255.255.0
interface Serial0
ip address 172.16.5.1 255.255.255.0
bandwidth 38
router eigrp 100
network 172.16.0.0
router igrp 100
network 172.16.0.0
Router r4 configuration
hostname r4
enable password cisco
interface Loopback0
ip address 172.16.6.1 255.255.255.0
interface Serial0
ip address 172.16.5.2 255.255.255.0
bandwidth 38
clockrate 38400
router eigrp 100
network 172.16.0.0
Examine the routing tables for routers r1 and r4 and determine what has happened.
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
I 172.16.4.0 [100/1110] via 172.16.3.2, 00:00:20, FastEthernet0/0
I 172.16.5.0 [100/265267] via 172.16.3.2, 00:00:20, FastEthernet0/0
I 172.16.6.0 [100/265767] via 172.16.3.2, 00:00:20, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
r4#show ip route
172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
D 172.16.4.0/24 [90/67905792] via 172.16.5.1, 00:12:12, Serial0
D 172.16.5.0/28 [90/68392192] via 172.16.5.1, 00:12:12, Serial0
C 172.16.5.0/24 is directly connected, Serial0
C 172.16.6.0/24 is directly connected, Loopback0
D EX 172.16.2.0/24 [170/68036352] via 172.16.5.1, 00:12:12, Serial0
D EX 172.16.3.0/24 [170/67908352] via 172.16.5.1, 00:12:12, Serial0
The configuration for router r3 did not redistribute routes from IGRP into EIGRP nor redistribute routes from EIGRP into IGRP, yet routers r1 and r4 can see all the routes. Since IGRP and EIGRP are similar routing protocols, route redistribution is automatic.
The scenario using different length subnet masks and a different major network number in the two routing domains will have no problems redistributing routes between IGRP and EIGRP. We need to examine what will happen when we use different subnet mask lengths in the two routing domains with IGRP and EIGRP. Reconfigure routers r3 and r4 with a 12-bit subnet mask while leaving routers r1 and r2 with an 8-bit subnet mask.
Router r3 configuration
interface Serial0
ip address 172.16.5.1 255.255.255.240
bandwidth 38
Router r4 configuration
interface Loopback0
ip address 172.16.6.1 255.255.255.240
interface Serial0
ip address 172.16.5.2 255.255.255.240
bandwidth 38
clockrate 38400
r1#show ip route
172.16.0.0/24 is subnetted, 4 subnets
I 172.16.4.0 [100/1110] via 172.16.3.2, 00:00:03, FastEthernet0/0
I 172.16.5.0 [100/265267] via 172.16.3.2, 00:00:03, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
r4#show ip route
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.4.0/24 [90/67905792] via 172.16.5.1, 00:00:44, Serial0
C 172.16.5.0/28 is directly connected, Serial0
C 172.16.6.0/28 is directly connected, Loopback0
D EX 172.16.2.0/24 [170/68036352] via 172.16.5.1, 00:00:44, Serial0
D EX 172.16.3.0/24 [170/67908352] via 172.16.5.1, 00:00:44, Serial0
As expected, the EIGRP domain can see the redistributed IGRP routes but the IGRP domain cannot see the EIGRP routes. This is the same problem that occurred when we were redistributing RIP and EIGRP, IGRP cannot handle VLSM so the EIGRP routes will not be redistributed. This problem can be fixed in the same manner by using static routes and then redistributing them into the proper protocol.
We have examined redistributing routes between RIP version 1, RIP version 2, IGRP, and EIGRP. Similar problems exist with all the pairs of protocols when VLSM is involved. The techniques to overcome the VLSM shortcomings of RIP version 1 and IGRP can be overcome with the judicious use of static routes. The techniques using route maps is applicable for all the protocols that have been examined thus far.
Before moving on to route redistribution involving OSPF we will examine a technique of selective route redistribution. In all the preceding scenarios we have redistributed, or at least tried to redistribute, all routes from one routing protocol into another. The situation may arise where we only need to redistribute a subset of the routes from one routing domain into another. For example, using our current IGRP/EIGRP configuration with the EIGRP subnet mask changed to an 8-bit mask so it matches the IGRP domain subnet mask, router r3 is redistributing two routes, 172.16.2.0 and 172.16.3.0 from the IGRP domain into the EIGRP domain. What if we only want to redistribute the route to network 172.16.2.0 into the EIGRP domain and block the route to the 172.16.3.0 network into the EIGRP domain? The answer is through the use of distribution lists. A distribution list is used to filter routes that are redistributed between protocols. For an example, we want to configure router r3 so that it only imports the 172.16.2.0 route from the IGRP domain and injects this route into the EIGRP domain. There are multiple ways to filter routes from routing updates so let’s start at the beginning. Enter EIGRP router configuration mode on router r3 and list the parameters for a distribution list.
r3(config)#router eigrp 100
r3(config-router)#distribute-list ?
<1-199> A standard IP access list number
The first parameter gives us a choice of either using a standard IP access-list (1-99) or an extended IP access-list. We will first filter the routes using a standard IP access-list and then see what additional options we have with an extended IP access-list. Select IP access-list 1 and list the next parameter.
r3(config-router)#distribute-list 1 ?
in Filter incoming routing updates
out Filter outgoing routing updates
Route filters can be applied to either incoming routing updates or outgoing routing updates. The route that we want to filter out, 172.16.3.0, is coming in the ethernet interface and going out the serial interface on router r3. The incoming route is an IGRP route so we cannot perform EIGRP route filtering on the input. Select out and list the next parameter.
r3(config-router)#distribute-list 1 out ?
Ethernet IEEE 802.3
Loopback Loopback interface
Null Null interface
Serial Serial
bgp Border Gateway Protocol (BGP)
connected Connected
egp Exterior Gateway Protocol (EGP)
eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)
igrp Interior Gateway Routing Protocol (IGRP)
isis ISO IS-IS
iso-igrp IGRP for OSI networks
ospf Open Shortest Path First (OSPF)
rip Routing Information Protocol (RIP)
static Static routes
<cr>
We have a number of choices to select from. The first choice is to filter the EIGRP route going out any interface.
r3(config-router)#distribute-list 1 out
Selecting this option, the outgoing EIGRP route updates on any interface of router r3 will be filtered according to access-list 1. Access-list 1 will be used to block the 172.16.3.0 route and permit all other routes. The list to use in this situation is shown below.
Router r3 access-list
access-list 1 deny 172.16.3.0 0.0.0.255
access-list 1 permit any
Don’t forget the permit any statement in the access-list. Remember there is always an implicit deny all at the end of every access list. Examine the routing table for router r4 to see the effect of the route filter.
r4#show ip route
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
D 172.16.4.0/24 [90/67905792] via 172.16.5.1, 00:00:00, Serial0
C 172.16.5.0/28 is directly connected, Serial0
C 172.16.6.0/28 is directly connected, Loopback0
D EX 172.16.2.0/24 [170/68036352] via 172.16.5.1, 00:00:00, Serial0
The second choice, using an extended IP access filter, can also be used to block the route to network 172.16.3.0.
Router r3 access-list
access-list 100 deny ip any 172.16.3.0 0.0.0.255
access-list 100 permit ip any any
The route to block is input in the extended IP access list as the destination address. The effect can be seen in router r4’s routing table.
r4#show ip route
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
D 172.16.4.0/24 [90/67905792] via 172.16.5.1, 00:00:01, Serial0
C 172.16.5.0/28 is directly connected, Serial0
C 172.16.6.0/28 is directly connected, Loopback0
D EX 172.16.2.0/24 [170/68036352] via 172.16.5.1, 00:00:01, Serial0
The second choice is to filter the route to network 172.16.3.0 from routing updates going out only the serial interface using a standard IP access-list.
r3(config-router)#distribute-list 1 out serial 0
access-list 1 deny 172.16.3.0 0.0.0.255
access-list 1 permit any
This distribution list will block the 172.16.3.0 route from EIGRP routing updates. We can prevent selected routes from being redistributed into another protocol with a distribution list. For example, block the 172.16.6.0 EIGRP route from being redistributed into IGRP.
Router r3 configuration
router eigrp 100
network 172.16.0.0
distribute-list 2 out igrp 100
access-list 2 deny 172.16.6.0 0.0.0.255
access-list 2 permit any
This form will prevent the 172.16.6.0 route from being redistributed into IGRP process number 100 so routers r1 and r2 will never receive this route from IGRP.
r1#show ip route
172.16.0.0/24 is subnetted, 4 subnets
I 172.16.4.0 [100/1110] via 172.16.3.2, 00:00:33, FastEthernet0/0
I 172.16.5.0 [100/265267] via 172.16.3.2, 00:00:33, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
If you don’t see the route to network 172.16.5.0 make sure that you have changed the subnet mask in the EIGRP domain to an 8-bit subnet mask (255.255.255.0).
These filtering examples were used to block routes that were being output either to a particular interface or to a particular routing protocol. Input route filters can also be used to block routing updates. For example, to block the 172.16.3.0 route from router r4 we can use an input route filter on router r4 instead of an output router filer on router r3. Before proceeding remove all the distributions lists from router r3.
r4(config)#router eigrp 100
r4(config-router)#distribute-list ?
<1-199> IP access list number
r4(config-router)#distribute-list 1 ?
in Filter incoming routing updates
out Filter outgoing routing updates
r4(config-router)#distribute-list 1 in ?
Ethernet IEEE 802.3
Loopback Loopback interface
Null Null interface
Serial Serial
<cr>
r4(config-router)#distribute-list 1 in serial 0 ?
<cr>
access-list 1 deny 172.16.3.0 0.0.0.255
access-list 1 permit any
r4#show ip route
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.4.0/24 [90/67905792] via 172.16.5.1, 00:00:02, Serial0
D 172.16.5.0/28 [90/68392192] via 172.16.5.1, 00:00:02, Serial0
C 172.16.5.0/24 is directly connected, Serial0
C 172.16.6.0/24 is directly connected, Loopback0
D EX 172.16.2.0/24 [170/68036352] via 172.16.5.1, 00:00:02, Serial0
In summary, distribution lists can be used to filter incoming or outgoing routing updates on all router interfaces or on a particular interface. A distribution list can also be used to filter the routes that are being redistributed into another routing protocol. All the filtering examples that we have seen were applied to the EIGRP routing process but they can also be applied to RIP and IGRP, but not OSPF. Why not OSPF? RIP, IGRP and EIGRP send and receive routing updates that contain routes. This may sound like a silly statement but it is true. OSPF routing updates do not contain routes, they contain link state advertisements. The OSPF shortest path first algorithm generates OSPF routes. All routers in the same OSPF area have an identical link state database. A distribution list cannot, and should not, change this fact. So remember to never use a distribution list with OSPF.
OSPF and RIP
The network in figure 13.9 will be used to examine the interactions between OSPF and RIP.
Figure 13.9. Example network for OSPF and RIP route redistribution.
Router r1 configuration
hostname r1
enable password cisco
interface Loopback0
ip address 172.16.2.1 255.255.255.0
interface FastEthernet0/0
ip address 172.16.3.1 255.255.255.0
router ospf 100
network 172.16.3.0 0.0.0.255 area 0
network 172.16.2.0 0.0.0.255 area 51
Router r2 configuration
hostname r2
enable password cisco
interface Ethernet0
ip address 172.16.4.1 255.255.255.0
interface FastEthernet0
ip address 172.16.3.2 255.255.255.0
router ospf 100
network 172.16.4.0 0.0.0.255 area 2
network 172.16.3.0 0.0.0.255 area 0
Router r3 configuration
enable password cisco
interface Ethernet0
ip address 172.16.4.2 255.255.255.0
interface Serial0
ip address 172.16.5.1 255.255.255.0
bandwidth 38
router ospf 100
redistribute rip metric 10
network 172.16.4.0 0.0.0.255 area 2
router rip
redistribute ospf 100 metric 1
passive-interface Ethernet0
network 172.16.0.0
Router r4 configuration
hostname r4
enable password cisco
interface Loopback0
ip address 172.16.6.1 255.255.255.0
interface Serial0
ip address 172.16.5.2 255.255.255.0
bandwidth 38
clock rate 38400
router rip
network 172.16.0.0
Redistributing has been configured on router r3 in figure 13.9. The ethernet interface has been configured as a passive interface for the RIP routing protocol. There is no need to broadcast RIP routing updates out interface ethernet 0 since there is no a RIP routing process on router r2 to receive them. The redistributed OSPF routes are assigned a metric of 1 and the redistributed RIP routes are assigned a metric of 10.
router ospf 100
redistribute rip metric 10
network 172.16.4.0 0.0.0.255 area 2
router rip
redistribute ospf 100 metric 1
passive-interface Ethernet0
network 172.16.0.0
List the routing tables of routers r1 and r4 in order to observe the results of the route redistribution between RIP and OSPF.
r1#show ip route
172.16.0.0/24 is subnetted, 3 subnets
O IA 172.16.4.0 [110/11] via 172.16.3.2, 00:10:29, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
r4#show ip route
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
R 172.16.4.0/24 [120/1] via 172.16.5.1, 00:00:26, Serial0
C 172.16.5.0/24 is directly connected, Serial0
C 172.16.6.0/24 is directly connected, Loopback0
R 172.16.3.0/24 [120/1] via 172.16.5.1, 00:00:26, Serial0
R 172.16.2.1/32 [120/1] via 172.16.5.1, 00:00:26, Serial0
What has happened is very interesting. The OSPF routes were successfully redistributed into RIP, as seen by router r4’s routing table. The RIP routes have not been successfully redistributed into OSPF as shown by router r1’s routing table. How could this happen since OSPF has been advertised as a better routing protocol. The answer is very simple. When RIP is redistributed into OSPF using the configuration for router r3, only routes having a 16-bit subnet mask will be redistributed into OSPF since the network is a class B network and class B networks have an natural subnet mask that is 16 bits in length. The RIP domain has been subnetted using a 24-bit subnet mask so the RIP routes will not be redistributed into OSPF. We can see this by creating a loopback interface on router r3 with a class B address and 16-bit subnet mask.
Router r3 configuration changes
interface Loopback0
ip address 173.16.1.1 255.255.0.0
router rip
redistribute ospf 100 metric 1
passive-interface Ethernet0
network 172.16.0.0
network 173.16.0.0
No changes need to be made to the OSPF router configuration on router r3. The routing table for router r1 should now contain a router to network 173.16.0.0.
r1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 3 subnets
O IA 172.16.4.0 [110/11] via 172.16.3.2, 00:19:27, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
O E2 173.16.0.0/16 [110/10] via 172.16.3.2, 00:01:08, FastEthernet0/0
For OSPF to be able to redistribute RIP routes that are not using a natural subnet mask we must instruct OSPF to redistribute the subnet information for the RIP routes.
Enter configuration commands, one per line. End with CNTL/Z.
r3(config)#router ospf 100
r3(config-router)#redistribute rip metric 1 ?
metric Metric for redistributed routes
metric-type OSPF/IS-IS exterior metric type for redistributed routes
route-map Route map reference
subnets Consider subnets for redistribution into OSPF
tag Set tag for routes redistributed into OSPF
<cr>
The keyword subnets needs to be used when redistributing RIP into OSPF. The new OSPF configuration will allow the RIP routes to be redistributed into OSPF
router ospf 100
redistribute rip metric 10 subnets
network 172.16.4.0 0.0.0.255 area 2
Router r1 will now have routes to all the networks in the RIP routing domain.
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
O IA 172.16.4.0 [110/11] via 172.16.3.2, 00:27:08, FastEthernet0/0
O E2 172.16.5.0 [110/10] via 172.16.3.2, 00:00:54, FastEthernet0/0
O E2 172.16.6.0 [110/10] via 172.16.3.2, 00:00:54, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
O E2 173.16.0.0/16 [110/10] via 172.16.3.2, 00:00:54, FastEthernet0/0
The routes that were redistributed from RIP into OSPF have been tagged as external type 2 routes. Recall from chapter 6 that there are two types of external routes. External type 1 has a metric that is the sum of the cost to cross the OSPF domain plus the cost of the route from the egress point of the OSPF domain to the route. An external type 2 metric only reflects the cost from the egress point of the OSPF domain to the route. The default type for OSPF external routes is type 2 as can bee seen in router r1’s routing table. The external route type can be set in the OSPF redistribution command.
r3(config)#router ospf 100
r3(config-router)#redistribute rip metric 10 ?
metric Metric for redistributed routes
metric-type OSPF/IS-IS exterior metric type for redistributed routes
route-map Route map reference
subnets Consider subnets for redistribution into OSPF
tag Set tag for routes redistributed into OSPF
<cr>
r3(config-router)#redistribute rip metric 10 metric-type ?
1 Set OSPF External Type 1 metrics
2 Set OSPF External Type 2 metrics
r3(config-router)#redistribute rip metric 10 metric-type 1 subnets
The effect of setting the metric type of the redistributed routes is shown in router r1’s routing table.
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
O IA 172.16.4.0 [110/11] via 172.16.3.2, 00:29:52, FastEthernet0/0
O E1 172.16.5.0 [110/21] via 172.16.3.2, 00:00:06, FastEthernet0/0
O E1 172.16.6.0 [110/21] via 172.16.3.2, 00:00:06, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
O E1 173.16.0.0/16 [110/21] via 172.16.3.2, 00:00:06, FastEthernet0/0
If we want to set the metric type for network 172.16.5.0 to type 1 and for all other redistributed routes to type 2 then a route map would need to be employed.
router ospf 100
redistribute rip metric 10 subnets route-map ospf_type
network 172.16.4.0 0.0.0.255 area 2
access-list 1 permit 172.16.5.0 0.0.0.255
route-map ospf_type permit 10
match ip address 1
set metric-type type-1
route-map ospf_type permit 20
set metric-type type-2
When OSPF redistributes a RIP route the route-map named ospf_type will be consulted. If the route matches the network of access-list 1 then the metric type will be set to 1. If the route does not match the network of access-list 1 then the next statement in the route-map will be executed. There is no match statement so all other routes will have their metric type set to type 2.
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
O IA 172.16.4.0 [110/11] via 172.16.3.2, 00:51:15, FastEthernet0/0
O E1 172.16.5.0 [110/21] via 172.16.3.2, 00:04:16, FastEthernet0/0
O E2 172.16.6.0 [110/10] via 172.16.3.2, 00:03:16, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
O E2 173.16.0.0/16 [110/10] via 172.16.3.2, 00:03:16, FastEthernet0/0
Routers r1 and r2 are area border routers since they have interfaces in more than one OSPF area. Router r3 is an autonomous system border router (ASBR) since it has an interface in the OSPF domain and the RIP domain.
r2#show ip ospf border-routers
OSPF Process 100 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 172.16.2.1 [1] via 172.16.3.1, FastEthernet0, ABR, Area 0, SPF 5
i 172.16.5.1 [10] via 172.16.4.2, Ethernet0, ASBR, Area 2, SPF 4
In chapter 10, Configuring OSPF, the area range command was used to summarize routes from a non-backbone OSPF area into area 0. External routes can be summarized by an ASBR. Configure two additional loopback interfaces on router r4 and enable RIP to advertise these routes.
Router r4 configuration changes
interface Loopback1
ip address 200.16.10.1 255.255.255.0
interface Loopback2
ip address 200.16.11.1 255.255.255.0
router rip
network 172.16.0.0
network 200.16.11.0
network 200.16.10.0
OSPF will redistribute these new RIP routes on router r3 and they will be propagated to routers r1 and r2.
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
O IA 172.16.4.0 [110/11] via 172.16.3.2, 01:05:33, FastEthernet0/0
O E1 172.16.5.0 [110/21] via 172.16.3.2, 00:12:53, FastEthernet0/0
O E2 172.16.6.0 [110/10] via 172.16.3.2, 00:12:53, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
O E2 173.16.0.0/16 [110/10] via 172.16.3.2, 00:12:53, FastEthernet0/0
O E2 200.16.10.0/24 [110/10] via 172.16.3.2, 00:02:01, FastEthernet0/0
O E2 200.16.11.0/24 [110/10] via 172.16.3.2, 00:02:01, FastEthernet0/0
Route summarization can be used on router r3 to reduce the amount of routing information that is injected from the RIP domain into the OSPF domain.
r3(config)#router ospf 100
r3(config-router)#summary-address ?
A.B.C.D IP summary address
r3(config-router)#summary-address 200.16.0.0 ?
A.B.C.D Summary mask
r3(config-router)#summary-address 200.16.0.0 255.255.0.0 ?
<cr>
The two class C networks on router r4 have been summarizing using the supernet 200.10.0.0 as shown in router r1’s routing table.
r1#show ip route
172.16.0.0/24 is subnetted, 5 subnets
O IA 172.16.4.0 [110/11] via 172.16.3.2, 00:00:02, FastEthernet0/0
O E1 172.16.5.0 [110/21] via 172.16.3.2, 00:00:02, FastEthernet0/0
O E2 172.16.6.0 [110/10] via 172.16.3.2, 00:00:02, FastEthernet0/0
C 172.16.2.0 is directly connected, Loopback0
C 172.16.3.0 is directly connected, FastEthernet0/0
O E2 173.16.0.0/16 [110/10] via 172.16.3.2, 00:00:02, FastEthernet0/0
O E2 200.16.0.0/16 [110/10] via 172.16.3.2, 00:00:02, FastEthernet0/0
An OSPF process can also advertise a default route and declare that itself as the originator of the default route. To accomplish this we need to configure a default route and then allow OSPF to advertise that it is the originator of the route.
Router r3 OSPF configuration
router ospf 100
summary-address 200.16.0.0 255.255.0.0
redistribute rip metric 10 subnets tag 666 route-map ospf_type
network 172.16.4.0 0.0.0.255 area 2
default-information originate metric 10
r2#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is 172.16.4.2 to network 0.0.0.0
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
C 172.16.4.0/24 is directly connected, Ethernet0
O E1 172.16.5.0/24 [110/20] via 172.16.4.2, 00:26:54, Ethernet0
O E2 172.16.6.0/24 [110/10] via 172.16.4.2, 00:26:54, Ethernet0
O IA 172.16.2.1/32 [110/2] via 172.16.3.1, 01:19:28, FastEthernet0
C 172.16.3.0/24 is directly connected, FastEthernet0
O E2 173.16.0.0/16 [110/10] via 172.16.4.2, 00:11:42, Ethernet0
O*E2 0.0.0.0/0 [110/10] via 172.16.4.2, 00:12:07, Ethernet0
O E2 200.16.0.0/16 [110/10] via 172.16.4.2, 00:11:31, Ethernet0
OSPF and IGRP
Every issue that we examined for the case of OSPF and RIP redistribution is applicable to OSPF and IGRP redistribution. To verify this claim replace the RIP routing processes on routers r3 and r4 with IGRP as shown in figure 13.10.
Figure 13.10. Example network for OSPF and IGRP route redistribution.
Router r3 configuration
router ospf 100
summary-address 200.16.0.0 255.255.0.0
redistribute igrp 100 metric 10 subnets
network 172.16.4.0 0.0.0.255 area 2
default-information originate metric 10
router igrp 100
redistribute ospf 100 metric 38 2000 255 1 1500
network 173.16.0.0
network 172.16.0.0
Router r4 configuration
router igrp 100
network 172.16.0.0
network 200.16.10.0
network 200.16.11.0
Remember to use the subnets keyword when redistributing IGRP into OSPF. One final form of the redistribute command that we need to cover uses the parameter match.
r3(config-router)#redistribute ospf 100 ?
match Redistribution of OSPF routes
metric Metric for redistributed routes
route-map Route map reference
<cr>
r3(config-router)#redistribute ospf 100 match ?
external Redistribute OSPF external routes
internal Redistribute OSPF internal routes
r3(config-router)#redistribute ospf 100 match external ?
1 Redistribute external type 1 routes
2 Redistribute OSPF external type 2 routes
external Redistribute OSPF external routes
internal Redistribute OSPF internal routes
match Redistribution of OSPF routes
metric Metric for redistributed routes
route-map Route map reference
<cr>
OSPF has three types of routes, internal, external type 1, and external type 2. When we redistribute OSPF routes using the command
redistribute ospf 100 metric 38 1000 255 1 1500 subnets
all OSPF routes, internal, external type 1, and external type 2, are all automatically redistributed. We can selectively choose which types of routes we want to redistribute. The following forms of the redistribute command and their effect are listed below.
redistribute ospf 100 metric 38 1000 255 1 1500 subnets match external internal
and
redistribute ospf 100 metric 38 1000 255 1 1500 subnets
are equivalent. In fact if you type in the first form and list the configuration you will see the second form. Both forms will redistribute all OSPF routes.
Redistribute ospf 100 metric 38 1000 255 1 1500 subnets match external
This form will only redistribute OSPF external type 1 and type 2 routes and will block all OSPF internal routes.
Redistribute ospf 100 metric 38 1000 255 1 1500 subnets match external 1
This form will only redistribute OSPF external type 1 routes and will block all OSPF internal routes and external type 2 routes.
Redistribute ospf 100 metric 38 1000 255 1 1500 subnets match external 2
This form will only redistribute OSPF external type 2 routes and will block all OSPF internal routes and external type 1 routes.
Redistribute ospf 100 metric 38 1000 255 1 1500 subnets match internal
This form will only redistribute OSPF internal routes and will block all OSPF external routes. All forms can be used with RIP and EIGRP. An alternative is to redistribute all OSPF routes and then use a route map to selectively block internal and external routes.
The final situation concerning IGRP and OSPF redistribution is the problem that occurs if OSPF is using VLSM. We know that IGRP cannot handle VLSM and OSPF will only redistribute those OSPF routes that have the same subnet mask as the IGRP domain. For example, if we create two new loopback interfaces on router r1 using a subnet mask that does not match the subnet mask IGRP is using then IGRP will not see the routes.
Router r1 configuration
interface Loopback1
ip address 172.16.20.1 255.255.255.240
interface Loopback2
ip address 172.16.20.17 255.255.255.240
router ospf 100
network 172.16.3.0 0.0.0.255 area 0
network 172.16.2.0 0.0.0.255 area 51
network 172.16.20.0 0.0.0.15 area 3
network 172.16.20.16 0.0.0.15 area 3
area 3 range 172.16.20.0 255.255.255.0
r4#show ip route
172.16.0.0/24 is subnetted, 4 subnets
I 172.16.4.0 [100/265257] via 172.16.5.1, 00:00:01, Serial0
C 172.16.5.0 is directly connected, Serial0
C 172.16.6.0 is directly connected, Loopback0
I 172.16.3.0 [100/266157] via 172.16.5.1, 00:00:01, Serial0
C 200.16.10.0/24 is directly connected, Loopback1
C 200.16.11.0/24 is directly connected, Loopback2
There are two ways to propagate networks 172.16.20.0 and 172.16.20.16 into the IGRP domain. The first is with a static route. We can create the static route on router r3 and redistribute it into IGRP or we can create a static route on router r4. The static route would have to have the same subnet mask length as the IGRP domain.
ip route 172.16.20.0 255.255.255.0 Serial0
This static route is sufficient to reach both of the loopback interfaces on router r1. The other method is to use the area range command on router r1 and summarize the two loopback addresses into on route with an 8-bit subnet mask.
area 3 range 172.16.20.0 255.255.255.0
These techniques also apply to RIP version 1.
OSPF and EIGRP
Every issue that we examined for the case of OSPF and IGRP redistribution is applicable to OSPF and EIGRP redistribution. If you feel the need, replace the IGRP routing process on routers r3 and r4 with EIGRP and verify that everything that we have covered with respect to OSPF router redistribution still applies.
![]() Chapter: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
Reserve your copy at a Beta Bookstore near you! |
Contact Bet@books © 1998 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Beta Book is subject to the rules stated in the Terms of Use. |